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Abstract 

A paper [5] has recently been published. This paper is faulty: 1) The standard 
requirements about the definition of an algorithm are not respected, 2) The main point 
in the complexity study, namely the functional programming component, is absent. The 
Editorial Board of the SIAM JC had been warned a confirmed publication would be 
openly commented, it is the role of this textfl 


1 History of the subject. 

I started the subject of Effective Homology in 1984, trying first to implement the 
Edgar Brown’s “algorithm” [4] computing the homotopy groups of the finite simply 
connected simplicial sets. This idea was quickly understood as ridiculous; thirty 
years later, there remains difficult to hope for an actual implementation of this 
algorithm, much too complex. 

Other methods were soon imagined to overcome the essential difficulty, con¬ 
sisting in using the strange power of the functional programming. Julio Rubio’s 
contribution was essential to make the project succeed: he understood in 1989 that 
the best theoretical tool to organize the work is the so-called Basic Perturbation 
Lemma Pi, more and more often called now the Homological Perturbation The¬ 
orem., you may question Google (Galway perturbation) to see numerous examples. 

Using Julio’s idea, a program called EAT (Effective Algebraic Topology) was 
soon obtained in 1990, mainly devoted to the computation of the homology groups 
of iterated loop spaces, already allowing us to produce homology groups so far 
unreachable by the “standard” methods. 

In the years 1995-8, Xavier Dousson’s thesis was devoted to the calculation 
of homotopy groups; the same tools, functional programming combined with the 
homological perturbation theorem, were successfully applied to the so-called White- 
head and Postnikov towers, the most “elementary” methods to compute the ho¬ 
motopy groups. Leading to the Kenzo program p5j. In particular, Ana Romero 
extended the scope of the program to the classifying spaces of non-commutative 

1 Kent Pitman informed me that the esoteric form #’ (lambda . . .) is no longer necessary in 
ANSI Common Lisp; the text is updated to the simpler form (lambda . . .). 
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groups, detecting an error [8] in a published paper, for a homotopy group of a 
relatively contorted simplicial set. 

These programs, once the basics of algebraic topology are understood, are 
elementary and certainly not the best possible: it is well known the Adams spectral 
sequence and all its derivatives are central in the subject and efficient methods must 
use them. Nevertheless, the experience of the Kenzo program, where everything is 
so elementary, made tempting a non-negligible theoretical result: If a dimension n 
is fixed, our algorithm computing the homotopy group 7T n X of a simply connected 
simplicial set X has a polynomial complexity with respect to X ; of course not with 
respect to n, as it is well known since David Anick’s paper [T] , unless P = NP. 

This polynomiality result is so natural when you know the details of the Kenzo 
program, and of course the authors of the corresponding 16000 lines of Lisp code 
know these details, that I often stated this result without any other justification. 
The authors of p)j, after a few years of interesting common work with myself on 
problems of constructive algebraic topology, suggested to write down a common 
paper on this polynomiality result. Why not. 

First Jiri Matousek identified a real difficulty that I had not seen: the program 
rests on the effective homology of the Eilenberg-MacLane spaces, itself based on 
the effective homology of K( Z, 1), quite simple, but the standard effective homol¬ 
ogy of this monstrous version of the circle S 1 has exponential complexity! Jiri 
solved the problem for K(N, 1), using a lovely discrete vector held, and I gave 
the complement to obtain the same result for K( Z, 1), essentially an elementary 
process of normalization. This is explained in [7]. 

No other obstacle against polynomiality was later found in the Kenzo algorithm 
where everything is elementary. The paper jj] is a rereading of the Kenzo source, 
or rather of the Kenzo documentation [TO], with some mathematical complements 
most often not included in the documentation. As it often happens in journalistic 
reports, the very nature of the Kenzo program is unfortunately in [5] misunder¬ 
stood. The authors have an excuse: it is hard to understand the core of such a 
program if you never worked with its source code, or if you never did some similar 
concrete programming work. 

Everything is elementary in Kenzo, except the functional programming compo¬ 
nent, to my knowledge so far never so essentially and intensively used in a computer 
program processing a specific mathematical problem. All the general programs 
“doing mathematics”, mainly computational algebra, such as Maple, Mathemat- 
ica, Axiom, Macsyma, Gap, Sage, ... also intensively use functional programming, 
it is inevitable, but the corresponding complexity problems are outside the scope 
of functional programming. To my knowledge, in our case, it is the first time an 
essential component of functional programming is used in a program doing a work 
as specific as computing a homotopy group. 

It so happened the authors of [5] in 2012 started preparing pages and pages 
about our problem of complexity. I soon warned them: sorry, your draft totally 
forgets the component functional programming ; without the minimal indications 
about this matter, the paper is not correct. For example, a Coq proof of this poly- 
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nomiality result could not avoid studying the cost of this functional programming. 
It was proposed I cosign the paper [5], I answered it is not possible to cosign a 
paper you would reject as referee. 

Every mathematican knows how it is difficult in conversations with non¬ 
mathematicians to explain what mathematical research is, and also why it is 
useful (!). Sometimes the same when a computer scientist tries to explain to 
“pure” mathematicians the exact nature of a computer program; and in particular 
where the difficulties are hidden. Modern programming, in particular functional 
programming with the so-called functional programming languages, seems so nat¬ 
ural for a pure mathematician, so close to his habits that he cannot believe some 
difficulty in complexity is hidden there. Finally it is not so hard to overcome this 
difficulty, but a few prerequisites cannot be avoided. It is the role of this text to 
clarify this point. 


2 Functional Programming. 


It is common in Mathematics to study functions taking as arguments one or several 
functions, the value of which being also a function. For example, an elementary 
exercise of topology could be: Let T := C([0,1], [0,1]) be the space of the continu¬ 
ous functions / : [0,1] —> [0,1] with the usual metric topology; prove the function 
F : F —>■ T : / i— > (/ o /) is continuous. The argument is /, a function, the value 
is / o f a function, and the problem concerns F, a function: function function. 


We want to study in this text the analogous situation in computer science. It 
is not difficult in most programming languages to write some code for functions 
having as value a function; in programming, we say such a function returns a 
function, to emphasize the dynamic character of the process: before been invoked, 
the “value” does not yet exist; when the dominating function is invoked , one says 
also it is called, its work starts and when the work is finished, a new object is born 
in the environment, a functional object, the object which is returned. This func¬ 
tional object may later in turn be invoked with appropriate arguments, returning 
arbitrary objects, maybe again other functional objects, why not. 


A programmer using such programming tools uses Functional Programming. 
Functional programming is more or less easy, depending on the programming lan¬ 
guage the programmer is using; some languages have been specifically organized 
in particular to make easy this style of programming, such a language then de¬ 
serves the qualifier functional. The main functional languages are those of the Lisp 
family, those of the ML family and Haskell. 


Algebraic Topology is often considered as a difficult subject, and our experience 
allows us to point out the main reason causing this difficulty. With only pen and 


2 This expression “Functional Programming” is also used for a strict style of programming 
where every (!) object is a function, the simplest example being the A-calculus, the wonderful 
theoretical machine invented by Alonzo Church to disprove Hilbert’s hope for a general algorithm 
solving any mathematical problem. More reasonably, most often, only the dynamic process 
defining how the program works then has a functional nature. 
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paper, you cannot reasonably practice functional programming, it is much too 
complex. A complexity which begins to be illustrated by the few diagrams of this 
text, used to explain the most elementary techniques which are necessary when 
implementing functional programming. So that an algebraic topologist wishing 
to work only with pen and paper must design quite sophisticated methods to 
overcome this essential difficulty or more precisely to use different strategies which 
avoid this obstacle: the exact and spectral sequences are not constructive; they 
become constructive only if you add an essential dose of functional programming in 
the recipes. Most often, our topologists must invent new high level exact sequences, 
spectral sequences, spectra, operads, ..., made of higher homology or homotopy 
operators, also of exotic spaces, with a constructive scope always limited, a scope 
which of course does not lower at all the interest of all these objects. While our 
methods using functional programming have a unique constructive limitation, the 
available material resources (computing time and memory space). 


3 Mathematics and Computer Science. 

It is not exceptional to observe mathematicians having a knowledge of computer 
science which is a little superficial. This is true for any domain of mathematics as 
well, but a mathematician often is not conscious of his exact status with respect 
to computer science, the source of many problems. 

Two extreme behaviours: some of them think a computer can only make es¬ 
sentially trivial computations, which “of course” cannot do any relevant work for 
“theoretical” Mathematics. I remember a high level topologist who, sincerely and 
honestly, declared he could not imagine a computer can determine whether a nat¬ 
ural number is prime or not. This happened frequently in the last decades of the 
20th century; many impressive results have been produced since then with the 
help of computers and it becomes difficult to find extreme examples of this sort. 

The opposite extreme, now more frequent, is the following. Some mathemati¬ 
cians think a computer is of course trivially able to implement any mathematical 
idea, and some of them are surprised when their idea, a little naive, in fact do not 
correspond to anything concretely feasible on a machine. Or is feasible but using 
non-trivial implementations, the study of which then needing significant and inter¬ 
esting work, in particular to justify theoretical mathematical results, for example 
in complexity. 

In a discussion with an excellent topologist, he explained a theoretical algorithm 
for computing homotopy groups is known for a long time: it is enough to use the 
combinatorial definition of the homotopy groups by Kan and Moore. He “only” 
forgot a finitely generated subgroup of a non-commutative free group of finite type 
is free, but not necessarily of Unite type and the claimed “algorithm” is not valid. 

Many topologists for example are persuaded the exact and spectral sequences of 
Algebraic Topology can be trivially transformed into algorithms computing some 
homology or homotopy groups. A referee recently claimed that deducing an al¬ 
gorithm from the Adams spectral sequence is “folklore”, sic. I naively thought 
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the mathematicians are the scientists the most careful for the precise definition of 
the objects they work with; it happens an algorithm is a non-trivial mathemati¬ 
cal object with a deterministic definition, due to the best representatives of our 
profession in the last century: Godel, Church and Turing, and such a definition 
cannot be reduced to some intuitive “folklore”. As long as the referee reports will 
be anonymous , such accidents will be frequent: Juridically, an expert cannot be 
anonymous, why this exception for the alleged “experts” judging our articles? 

This text is devoted to clarifying the particular case of functional programming. 
On the one hand, coding functions returning functions is now as easy in program¬ 
ming as in mathematics, mainly if you use a so-called functional programming 
language. On the other hand, the cost in complexity is essentially null , which is 
summarized by the title: Functional Programming is free ; good news, but why? 
Because of the subtle notion of closure ; of course the notion of closure in pro¬ 
gramming, unknown by most mathematicians and even by a large proportion of 
computer scientists. 

Some complex programs intensively use functional programming, and studying 
their complexity needs a lucid knowledge of this wonderful tool, the art of produc¬ 
ing closures. Working in this way, you obtain efficient programs, the structure of 
which is limpid; furthermore without any cost in complexity. It is the subject of 
this article to explain this notion of closure, not so complicated, but not trivial at 
all. 


4 Defining an algorithm. 

The paper [5j in principle proves some algorithm ir n : X i —> n n X is polynomial. 
Before proving this property, the algorithm 7r n must be available. 

The proof of a theorem is decomposed in simpler statements, often called propo¬ 
sitions , maybe in turn decomposed in still simpler statements, often called lemmas , 
and these lemmas should have simple proofs directly understandable. A similar 
scheme is to be applied for the definition of an algorithm. 

The execution of a program finally is sequential, instruction by instruction, 
so that the description of an algorithm consists in dividing the long sequence of 
instructions into partial segments, divided in turn in shorter segments, and so on, 
up to sufficiently elementary segments the implementation of which is a routine 
task. Often, smaller segments consist in fact in a call of a functional object done 
with respect to some prepared inputs, the caller waiting for the corresponding 
output returned by the functional object. This is the standard top-down view of 
algorithms, dual of the bottom-up understanding, the latter easier to handle when 
writing source code. 

The article [5] uses the Postnikov tower. The Whitehead tower is a little 
simpler, produces also the homotopy groups, but not the Postnikov c/asse^. The 
difficulty with respect to functional programming is the same for the Whitehead 

3 Often erroneously called Postnikov invariants. 
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tower and this framework is enough for our explanations. 

The process computing ir n X thanks to the Whitehead tower consists in itera¬ 
tively constructing the stages of the tower, so that the first level decomposition of 
the desired algorithm X i —> 7r n X is necessarily: 

y _ V . V V , V , H n. y 

vV — A 2 I- > A 3 ■ ■ • A n _i I- > A n I- > 7T n A 

The stage X t of the tower is the inital space X where the first homotopy groups 
7TjX have been “killed” for j < i, its homotopy starts at the index i. The Hurewicz 
theorem therefore allows the program to compute HjXi = n l X l = 7 uX, and an 
appropriate fibration using this group then produces the next stage X i+1 . The last 
step H n = 7r n is again an application of the Hurewicz theorem. The program starts 
with X = X 2 simply connected, without any homotopy in dimensions 0 and 1. 

An algorithm is a functional object “ input 1 —> output ” and the computer sci¬ 
entists know for a long time the appropriate types of the input and the output are 
to be carefully defined. I invite a reader sufficiently patient to reach this part of 
this text to analyse the article [5] with the Adobe searcher for the word “type”: 
the reader will see this matter of the (computer) types of the used objects is never 
considered. The reader must probably understand the definition of these types 
is a minor subject: the slave who some day maybe will implement the described 
algorithm should be able to find out these details. 

This matter of type is yet become central in the very foundations of mathemat¬ 
ics, see the Wikipedia page “Homotopy Type Theory”. A point which does not 
seem really understood by our authors. If they had taken a little care of this ques¬ 
tion of types, they would have realized some functional programming is inevitable 
in such a programming. 

In the first level decomposition of the Kenzo algorithm above, the main step is 
the partial algorithm rty : A'j_i e->■ -W The input and the output are a simplicial 
set with effective homology. We must therefore consider the (computer) type of the 
simplicial sets with effective homology. 

It is not the right place to define all the details of this quite complex computer 
type, a large collection of functional objects defining a simplicial set in general not 
of finite type, combined with a set of other functional objects sufficiently rich to 
contain the homotopy type of this simplicial set: this is nothing but the key point 
of Effective Homology. To illustrate our subject we just consider the simplest 
component of such an object, the face operator dx of a simplicial set X. 

Such a face operator is a functional object, and you must first define... the 
type of its input and output. The type of the simplices of X can be chosen as a 
dependent type S := NxSk where, for every integer n G N, the type S n is the type 
of the n-simplices of X. For example for the standard presentation of K (Z, 1), a 
simplicial set not of finite type even if we limit the dimension, S n is the type of the 
lists of length n made of integers. The face operator d is then a functional object: 

d : [Nx5„]xN» ->• [Nx S n ) : (( n,a),i ) ^ $(< 7 ) 
where a is an n-simplex of X and i an index 0 < i < n. For example for X = 
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K(7a, 1), a possible 4-simplex is a = ( — 19, —14, 8,4) and: 

3*r ( z,i)((4, (-19, -14, 8,4)), 2) = (3, (-19, -6,4)) 

Let Xi_i be a possible {i — l)-th stage of a Whitehead tower, necessarily im¬ 
plemented as a simplicial set with effective homology. This object contains a large 
collection of functional objects and in particular the face operator dx i _ 1 - The 
step Wi of the program must then construct X % := uy(W-i), the output X t being 
again a simplicial set with effective homology, this object containing in particular 
a similar collection of functional objects, in particular the face operator dx,', the 
construction of dx t depends of course on the object dx. l _ 1 , but also of all the other 
components of X % . in particular on the other functional components, according to 
a process computationnally not simple: a collection of various Eilenberg-MacLane 
spaces must in particular be constructed also as simplicial sets with effective ho¬ 
mology, each Eilenberg-MacLane space being again the output of a functional 
subprogram. 

The paper [5] does not consider at all the cost of the generation of all these 
functional objects. It is a pity: 

• On the one hand, this functional programming is the heart of the Kenzo 
algorithm: if such a programming tool was not necessary, the topologists 
would have used such an algorithm for a long time. 

• On the other hand, the complexity cost of the dynamic generation of the 
functional objects is in this particular case essentially null. The rest of this 
text is devoted to this point. 


5 A toy example. 

It could be interesting in a program, given two functional objects /i, f 2 : N —>• N, 
to be able to dynamically construct the composition f 2 o /i : N —>• N, to be used 
later for some reason. 

The Common Lisp style is convenient to illustrate such a situation. Let us 
consider this short Lisp session. 


> (setq fl (lambda (n) (* n 3))) 

#<Interpreted Function (unnamed) 0 #x20ec3b8a> 

> (setq f2 (lambda (n) (+ n 8))) 

#<Interpreted Function (unnamed) 0 #x20eca732> 

> (list (funcall fl 5) (funcall f2 5)) 

(15 13) 


The first statement defines a function labeled “fl' 7 mathematically defined as 
/i : n i— ^ 3n; read: assign to the symbol f 1 the function defined by the A-expression 
A n (n * 3); the same for f 2 : tmn+8. The last statement constructs a list, its first 
element is /i(5), the second one is / 2 (5). Notice the Lisp notation (funcall f 1 5) 
(read: call the function located by the symbol fl for the input 5) for the usual 
mathematical notation /i(5). 
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The reader may wonder why the returned functions are “unnamed”. In this 
organisation the symbol f 1 “sees” the functional object, while the functional object 
does not see at all the symbol f 1 . In particular, different symbols can see the same 
function. More concretely, the symbol fl has a pointer toward the functional 
object just created, and on the contrary, the functional object has no pointer 
toward fl. A mysterious string such as #x20dbc44a is the hexa machine address 
of the functional object. 

If we want now to work with f :i : — / 2 ° ,/'i, we can use the Lisp statement: 


> (setq f3 

(lambda (n) 

(funcall f2 (funcall fl n)))) 
#<Interpreted Function (unnamed) 0 #x20dda8d2> 

> (funcall f3 5) 

23 


But this is essentially static, the process constructing / 3 should be repeated if 
another composition is desired. If a program must construct a large number of 
compositions, it would be painful to rewrite the same sort of statement for each 
composition. It is better to write a general composition function: 


> (setq compose 

(lambda (af2 afl) 

(lambda (n) 

(funcall af2 (funcall afl n) ) ) ) ) 
#<Interpreted Function (unnamed) @ #x20e9bdf2> 

> (setq f4 (funcall compose f2 fl)) 
#<Interpreted Closure (unnamed) 0 #x20d9e092> 

> (funcall f4 5) 

23 

> (setq f5 (funcall compose fl f2)) >■£< 
#<Interpreted Closure (unnamed) 0 #x20ea93aa> 

> (funcall f5 5) ^ 

39 


You can read: the function compose is the function which, given the functions 
af2 and afl, returns the function which, given the integer n, returns af2(afl(n)). 

We have for example chosen the symbol afl as vaguely meaning “abstract 
function #1” to improve the readability, but any arbitrary symbol could have 
been chosen here, even the symbol fl. The qualifier “abstract” means that no 
concrete function is to be defined when the value of compose is constructed,-, only 
later, when the functional object is used, then the abstract function will be replaced 
by some “concrete” function, as you observe in the next statements. 

But the most important point in this short Lisp session is the following: the 
values of the constructed compositions f4 and f 5 are closures, not functions. What 
does this mean? It is the role of this text to clarify the exact nature of such 
an object, to illustrate the amazing power of these objects, on the one hand in 
flexibility, on the other hand their cost in complexity is essentially null. 







6 Functional objects. 


Except if you work with exotic machines, in particular machines allowing to use 
multiprocessing, a program is finally a sequence of machine instructions, sequen¬ 
tially executed, except when some specific instruction, a jump instruction, says 
the next instruction to be executed is to be taken at some machine address; the 
execution then again continues sequentially from this address up to the next jump, 
and so on. 

A program can also invoke a functional object, this functional object is then 
called a callee, while the program at the origin of this call is the caller. The 
callee must then execute some task, and when this task is finished, the control 
is given back to the caller. The scheme below illustrates such an organization; 
each rectangle contains some machine instruction, and the arrows show the path 
followed by the control. Such a call consists in two jumps, one starting the callee, 
the other one leaving it. 



In fact the caller, before invoking the callee, pushes onto the stack the return 
address ; in this way, when the callee has finished its task, it can read this return 
address to give back the control to the caller, at the next point where the caller 
must continue its work; the functional object can so be called from anywhere in 
the program, avoiding to repeat its code in the memory if this functional object is 
called several times, quite frequent. 

A part of the computer memory is called the stack ; it is a continuous area of 
the memory, where objects are piled, the system being allowed to add a new object 
onto it, or on the contrary to remove the last one having been added; a special 
system register always keeps the address of the last object. In particular, each time 
a functional object is launched for execution by a caller, the caller adds (pushes) 
the return address onto the stack, so that when the work of this functional object 
is finished, this address on the stack is used by the callee to return to the caller at 
the right place, and this return address is erased (popped); we will see this stack 
will be used also for another specific usage of the closures, quite essential. 

A closure is also a functional object, but with a sophisticated structure opening 
interesting new possibilities, in particular making easy functional programming. 
A closure is abstractly made of three components: 

• the body of the closure, containing mainly: 

— a pointer to its code ; 

— a collection of pointers defining its oum environment. 

• the code of this closure; 

• the environment of this closure. 


9 






The apparent redundancies in this description are voluntary. In a sense, the 
wonderful power of our computers is due to the intensive and remarkable use of 
the pointers ; a pointer is a machine object giving “only” the machine address of 
another machine object; and it is not so rare the last machine object is again a 
pointer, this is indirect addressing , the key point to implement the notion of closure 
(and many others). 

When the functional object closure will be invoked, its code will be executed, 
but a part of this code may use the specific environment of this closure, the pointers 
available in the body itself allowing the code to reach the relevant part of the 
current environment. 

There remains to detail how this game of pointers is really organized, and why 
this organization justifies the title of this text. 


7 The standard toy example. 

The standard mini-example which is used to explain the nature of the closures, 
quite artificial but instructive, is the following. Let us imagine a programmer 
wants to construct several arbitrary multipliers , a multiplier p rn being a functional 
object ready to multiply an arbitrary input n by some fixed number rn. In standard 
programming, you could write: 


> (setq mul3 (lambda (n) (* n 3))) ^ 
#<Interpreted Function (unnamed) 0 #x20d50b7a> 

> (funcall mul3 5) ^ 

15 


But our programmer intends to be able to dynamically , that is, during run¬ 
time , generate multipliers with various and arbitrary m’s, all these multipliers 
remaining simultaneously “alive”, and in particular such that they could be re- 
peatidly called in arbitrary orders. We assign a generator of multipliers to the 
symbol genmul, and immediately use it: 


> (setq genmul 

(lambda (m) 

(lambda (n) (* m n)))) ^ 

#<Interpreted Function (unnamed) 0 #x20d9c84a> 

> (setq mul5 (funcall genmul 5)) ^ 
#<Interpreted Closure (unnamed) @ #x20da2252> 

> (setq mul7 (funcall genmul 7)) ^ 
#<Interpreted Closure (unnamed) 0 #x20daf022> 

> (funcall mul5 9) ^ 

45 

> (funcall mul7 9) ^ 

63 


The reader is invited to “think” like Lisp when these statements are processed. 
This goes as follows. 


10 







• (setq genmul ...) : Lisp understands the user wants to use the symbol 
genmul and in particular assigns to it the object defined by the continuation 
of the text. 

• (lambda (m) . . .) : This object is an “ordinary” functional object, the input 
will be some object denoted by m in the source code and returning some 
output, some object defined by the subsequent text. Important: at this time 
this functional object does not work, it is then just generated and installed 
somewhere in the memory space; it will be called only later. We will also 
detail later, when this functional object is called, how it works. 

• ft happens the next statement (setq mul5 . . .) now calls genmul, more pre¬ 
cisely the functional object assigned to it, the input being 5. At this time, 
the binding “m i —> 5” defined by the parameter m and the input 5 is installed 
in the environment, more precisely in the local environment of the functional 
object just starting its work. 

• The body (lambda (n) . . .) of our functional object is then executed, which 
body asks again for the generation of a functional object, not its execution. 

• Lisp then “knows” this generation happens in a local environment, a local 
environment having in this case only the binding “m i —> 5”. Then Lisp gen¬ 
erates the next functional object (lambda (n) . . .), saving also the current 
local environment, that is, in this case the binding “m H > 5”, this environment 
being made visible only from the just created functional object. This pair 
made of a functional object and an environment valid only for this object is 
a closure , notion detailed later. This closure is the output of genmul for this 
invocation, which closure is assigned to mul5. 

• Same story for (setq mul7 . . .): another functional object is generated, as¬ 
signed to mul7, and this object, another closure, sees an environment where, 
this time the only binding is “m i —> 7”. This closure is assigned to mul7. 

• The value of mul5 is called with the argument 9, in other words, the binding 
“n I —> 9” is installed. The value of mul5 is a closure which still sees the 
binding “m i—>■ 5”, so that the code of our closure, the Lisp statement (* m n) 
returns 45. 

• The value of mul7 is called with the same argument 9, in other words, the 
binding “n i —> 9” is again installed. This value is a closure, not the same as 
the previous one, which sees the different binding “m i —> 7”, so that the body 
of this closure, the Lisp statement (* m n) this time returns 63. 

These details are a little lengthy but necessary to avoid deep misunderstand¬ 
ings. Usually the following “magic” explanation is given: a closure keeps the local 
environment which was present at generation time. A little more precisely: a 
closure encloses the local environment existing at generation time, explaining the 
terminology. Partially true, but in general not sufficient, and the actual process is 
more powerful. 
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8 Detailing the structure of the closure mul5. 


When genmul is called to generate the closure which will be assigned to mul5, Lisp 
does the following work. The local environment of this invocation of genmul has 
only the binding “m i—> 5”. Having to generate the functional object (lambda (n) 
(* m n), Lisp generates in fact only a small structure, the body of the closure to 
be generated, containing only three components: 

• A specific label indicating the object so entitled is a closure ; 

• The address of the code (lambda (n) (* m n); 

• The address of the machine word containing the value 5 for the symbol m, 
value valid only for this closure. 

You understand that, when genmul will be later called to generate a second 
closure assigned to mul7, another structure of the same sort is again generated, 
“disjoint” of the first one, with the same label, with, very important, the same 
address of the (same!) code, but the third component will be this time the address 
of the value 7 valid for this closure. 

You must carefully distinguish in this story the functional object which, when 
it is called, generates a closure: 

(lambda (m) 

(lambda (n) (* m n))) 

from the code (lambda (n) (* m n) of the generated closure. When the inter¬ 
preter or the compiler processes the functional object assigned to genmul, it “sees” 
this (ordinary) functional object will have to generate a closure. The compiler 
then generates somewhere the (interpreted or compiled) code of the closure, and 
this unique copy of this code will be used by every closure generated by genmul. 

However, this code, this unique code, according to the closure for which it is 
working, has to use different values for m, values defined beforehand, when the 
closure was generated; how this is possible? 

The solution is another use of the stack, already mentionned to keep the return 
address from a functional object. When Lisp executes (funcall mul5 9), Lisp 
works as follows: 

• (f uncall . . . ) means the value of the first argument mul5 of f uncall is a 
functional object. 

• Examining the nature of this functional object, in this case a closure, Lisp 
pushes on the stack three addresses: 

— The return address, which will be used as for an ordinary functional 
object; 

— The address of the closure. 

— The adress of the second argument 9. 

• This done, Lisp reads the address of the relevant code of this closure and 
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gives the control to this code. 



• In other words this code is now executed. 

• And when this code must use the value of m valid for this closure, the code 
has been prepared by the compiler to reach this value as follows: 

— Read the address of the closure from the stack; 

— Read the third component of the closure, which contains the address of 
the value of m valid for this closure. 

— Finally read the value of m valid for this closure. Typical use of indirect 
addressing. 

• Via the stack, the code of our closure can also reach when necessary the 
second argument 9 of funcall, that is, in this case, the unique argument n of 
the invoked closure. 

• When the execution of the code is finished, the code erases from the top of 
the stack the address of the argument 9 and the address of the closure, no 
longer necessary, reads the return address on the stack, erases also this return 
address, and is now able to return to the caller at the right place. 

• Most often, a functional object must also return an output , here 45; the 
address of the output which has just been computed by the closure is then 
put onto the stack, in this way the caller is able to reach this output. 

Such a process: 

• Preparing some input for a callee; 

• Giving control to this callee; 

• The callee does its work; 

• When the work is finished, the callee prepares the appropriate output; 

• The callee gives back the control to the caller; 

• All these steps using the stack to make the involved objects communicate 
between each other; 

is so essential in any programming language that the machine language has always 
specific instructions to conveniently and efficiently handle the top of the stack as 
roughly described above. Examine for example the entry “Stack instructions” in 
the Wikipedia page “x86 assembly language”. The particular case of the call of a 
closure is nothing but a variant of this process where the address of the closure is 
also put onto the stack, to allow the called code to reach the environment specific 
to this closure. 
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9 A local environment is alive. 


An acute reader maybe wondered why the closures above had their third compo¬ 
nent containing the address of the value of m and not this value itself, so needing 
an indirection. 

But consider the next standard toy example: 


> (setq make_package 
(lambda (m) 

(values 

(lambda (n) (* m n)) 

(lambda () (setq m (1+ m)))))) ^ 
#<Interpreted Function (unnamed) 0 #x20db5ala> 


The object assigned to the symbol make_package is an ordinary functional 
object using one argument m. When this object is called, it returns two values, 
namely two closures. The first one is a multiplier fi m as before. The second value 
is another closure which increases the value of m by 1. For example, we can call 
raake_package with the argument “m i— >• 5'’; the returned values are respectively 
assigned to the symbols mul_l and inc_l as follows: 


> (multiple-value-setq (mul_l inc_l) 

(funcall make_package 5)) 
#<Interpreted Closure (unnamed) 0 #x20dba7e2> 


Only the first closure assigned to mul_l is displayed. The same for two other 
closures where now “m i—>■ 18” , and the symbols mul_2 and inc_2 are used instead: 


> (multiple-value-setq (mul_2 inc_2) 

(funcall make_package 18)) ^ 
#<Interpreted Closure (unnamed) 0 #x20dbfb42> 


The reader probably guesses the continuation of the story: 


> (funcall mul_l -5) 

-25 

> (funcall inc_l) 

6 

> (funcall mul_l -5) ^ 
-30 

> (funcall mul_2 -5) ^ 
-90 

> (funcall inc_2) 

19 

> (funcall mul_2 -5) ^ 
-95 

> (funcall inc_l) 

7 

> (funcall mul_l -5) ^ 
-35 
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The new point is that both closures assigned to mul_l and inc_l share the 
same “local” variable m, for the environment containing the initial binding was the 
same for both closures. So that once inc_l has increased the value of m from 5 
to 6, the call of mul_l of course then uses the updated value of m. The same for 
the closures assigned to the symbols mul_2 and inc_2 with respect to their own 
local environment, another binding “m i —> 18”, updated to 19. 

These complications do not prevent for example mul_l and mul_2 to share the 
same code. The appropriate scheme is the following one. 


stack < 


n 


fn-obj 


return 


mul_l 


closure 


closure 

— 

|mul_2| 

code 



code 


m 



m 



(lambda (n) (* m n)) 


(lambda () 

(setq m (1+ m)) 


5 K 


inc_l 


18K 


closure 




closure < 

code 



v 

code 

m 



m 


inc_2 


The central components are the four closures, each one located by a symbol; 
in this way, the programmer can call them easily. These closures share some codes 
and share also some environments, but in this case not in parallel: if two closures 
share a code, they do not share an environment, and conversely. This, once the 
source code is interpreted or compiled, is static. 

In the diagram above, the state of the memory is also sketched when, a dynamic 
event, the closure located by mul_l is called with the argument 9. Then the control 
is given to the code of “(lambda (n) (* m n))”, reached via the closure, which code 
can reach the binding “m i— > 5” of the relevant environment via the stack and its 
fn-obj component; the code can reach the binding “n i —> 9” also via the stack. 

We hope this diagram could make clear the role of the closures: they are 
very small boxes containing the address of the corresponding code and also the 
addresses of the variables of the corresponding environment. When a closure is 
called, the control is given to the corresponding code, which reaches the appropriate 
arguments via the stack and the closure, in particular the variables of the closure 
itself. 

This is nothing but a toy example. In more general situations, it is quickly 
impossible to draw a planar diagram as above! Taking account of the descriptive 
power of the addressing mechanism - n bits can denote 2” different addresses! -, 
this is not at all a problem for the interpreter or the compiler. This is why, as it 
is detailed in the next section, functional programming is essentially free. 
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10 When is a closure generated? 


We hope the reader is now sufficiently advanced in this matter of closures to 
understand another point. Our reader could have been puzzled by the quoted 
adjective “ordinary” often attributed to a functional object. How the interpreter 
or the compiler can decide whether such an object must be “ordinary” or not, that 
is, in the negative case, a closure? 

Some global environment is always defined, that is, a collection of bindings 
everywhere visible in the program, except when such a binding is “hidden” by a 
local one; on the contrary a local environment is visible only from a small (local) 
part of the code, and also from the closures which were generated when this local 
environment was active. 

When a functional object is to be generated, Lisp examines the state of the 
environment where this generation is to be done. If only the global environment is 
visible, an ordinary functional object is generated; on the contrary, if the generation 
happens inside some local environment, then a closure is generated. 

The simplest way in Lisp to generate a local environment uses a let instruction. 


> (setq a 25) ^ 

25 

> (let ((a 255)) * 

(+ a a)) 

510 

> (+ a a) 

50 


In this short session above, two uses of the variable a coexist. The global 
environment defines a binding “a 25”, while, when the (let . . .) instruction 
is run, a local environment with the binding “a i —> 255" is defined. In this local 
environment, adding a and a produces 510, but this done, this local environment 
is definitively dead, so that in the next statement, the same code (+ a a) returns 
this time 50: the global environment was let unchanged and is reused as such. 

Combining a (let . . .) statement with generation of functional objects shows 
when the interpreter or the compiler decides to generate an ordinary functional 
object or a closure. 


> (setq addal (lambda (b) (+ a b))) ^ 
#<Interpreted Function (unnamed) @ #x20fl0aaa> 

> (setq adda2 

(let ((a 33)) 

(lambda (b) (+ a b)))) 

#<Interpreted Closure (unnamed) @ #x20d88cba> 

> (funcall addal 66) ^ 

91 

> (funcall adda2 66) ^ 

99 
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The functional object assigned to addal is generated when only the global en¬ 
vironment is visible, so that this object has only the status of (ordinary) function. 
On the contrary, the object to be assigned to adda2 is generated when the local 
environment with the local binding “a i —> 33” is active, so that this requires a 
closure saving this environment for later uses. 

This effect is more visible when the global and the local environment are both 
used in a closure. 


> (setq a 11) ^ 

11 

> (setq b 22) 

22 

> (setq add_a_b 

(let ((b 222)) 

(lambda (n) (+ a b n)))) ^ 
#<Interpreted Closure (unnamed) 0 #x20e60bca> 

> (funcall add_a_b 33) ^ 

266 

> (setq a 110) ^ 

110 

> (setq b 2) ^ 

2 

> (funcall add_a_b 33) ^ 

365 


The closure uses the global binding “a i— >• 11” and the local one “b i —> 222 ” the 
last biding hiding the global one “b i —> 22 ”. The first call computes 11 + 222 + 33 = 
266. Then the global bindings of a and b are modified. The second call of the 
closure computes 110 + 222 + 33 = 365; in other words, the closure uses the unique 
(global) binding of a, which has been modified by (setq a 110), but the local 
binding of b which is not changed by (setq b 2), this last setq changing only the 
global binding of b, which binding is hidden inside the local environment of the 
closure by its own local binding, unchanged. 

All the previous examples are artificial, just designed to make obvious how, 
in a good programming language, the interpreter and the compiler process the 
terrible problem of identifier scope in a relatively sophisticated but powerful way. 
This organization made of global environments, local environments and closures 
is the result of a long evolution of the art of programming; the interested readers 
can consult the Wikipedia page “Closure (computer programming)” to get some 
information about this evolution. 

The author of this note does not forget his serious difficulties when he tried in 
the 70’s to understand the very notion of the funarg problem in Maclisp, see: 

http://www.maclisp.info/pitmanual/eval.html 

when the birth of the notion of closure was just under way: the programmer had 
to manage himself the problem of identifier scope through the association lists. 
The discussion described in this web page is instructive to follow the hesitations 
of the best implemented of this time. 
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There remains to see why the use of these closures is free, we mean in complexity 
studies, and also why this organization is exactly the right one to implement 
high level mathematics, we mean when notions coming from the Category Theory, 
typically the functors, have to be implemented. 


11 Functional Programming is Free. 

We mean that, in a complexity study, the cost of the production of a new closure 
during the execution of a program is “null”, more exactly is constant. In most 
complexity studies, the input a of a program n is assumed to have a size a(a), 
the program is run to produce some output u = n(a), and we would like to bound 
the computing time T(n,a) in function of a (a). For example, the program n is 
said to be polynomial if an exponent e and a coefficient c can be determined, such 
that for any meaningful input a, the estimate t[ji, a) < c(l + cr(a)) e is satisfied. 

Let us assume we would like to prove the program tt is polynomial. If the 
number of closures to be produced is bounded independently of a, the fact that the 
cost of the production of a closure is constant implies the production time of these 
closures can be omitted: it is enough to increase the coefficient c to take account 
of the production of closures. Otherwise, when the number of closures depends 
on a, such a hasty claim could fail, but anyway using the fact the production cost 
of one copy of the closure is constant can be used conveniently. 

Producing a closure of a certain type is only allocating a memory segment 
of fixed length, a segment containing the label closure, the address of the cor¬ 
responding code, always the same, and the addresses of a fixed number of local 
values. 

Of course you must distinguish the computing time necessary to generate the 
closure from the computing time of the closure itself when it is called later by 
the program; this computing time can on the contrary strongly depend on the 
inputs given by the caller to the closure. For example the closure could be an 
Ackermann function depending on some parameters; the production of the closure 
is then constant, but the computing time of such a closure when it is called of 
course is not constant at all, depending on the input and also possibly on the 
specific parameters of this Ackermann function. 

The investigator in complexity must also be lucid about another factor. The 
production itself of a closure needs a constant time, but preparing the local en¬ 
vironment valid for this closure can on the contrary be costly, depending on the 
parameters of this closure. Let us consider for example the case of a function 
depending on a natural number n, this function having to produce a closure which 
must use the n-th prime number. It is then better to compute this prime number 
before generating the closure, and to insert the result in the environment known by 
the closure. In Common Lisp the structure of the function generating the closure 
could be: 
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> (setq closure_gen 
(lambda (n ...) 

(let ((nth_p (funcall nth_prime n))) 
(lambda (...) ... nth_p ...)))) 


The (ordinary) function assigned to closure_gen in particular depends on 
the natural number n and maybe on other arguments. The (let . . .) instruction 
inside the definition of the function enriches the current environment with a binding 
“nth_p i —y 13 ,: if the function is called with “n 6”; in other words, a function 
computing the n-th prime number is assumed assigned to the symbol nth_prime. 
This done, and maybe some other auxiliary work, the closure is generated inside 
the environment generated by the (let . . .); the closure therefore will keep the 
address of the value of nth_p, so that the code of the closure will be able to directly 
use this value without having to recalculate it. In such a situation, the cost of the 
calculation of the n-th prime is to be added to the cost of the generation of the 
closure. 

In other words, three steps when a closure is used: 

• Preparing the appropriate local environment, the cost depends on the specific 
necessary work; 

• Generating the closure itself, constant cost. 

• Using the closure when it is called, cost depending on the code of the closure, 
on the arguments given by the caller, and also possibly of the nature of the 
environment used by the closure. 

12 Implementing functors thanks to appropriate 
closures. 

To explain why the notion of closure is the right tool to implement functors, we 
use the following elementary example. Let us assume a programmer has to work 
with (the category of) monoids, and in particular, he must implement the product 
bifunctor. 

He decides a monoid is a pair, the first element being the identity of the monoid, 
the second one being the operation of the monoid. Such an operation is a process, 
a function, which, given two elements of the monoid computes their product. For 
example the additive monoid of the natural numbers could be implemented as: 


> (setq N+ (list 0 #’+)) ^ 
(0 #<Function +>) 


The cryptic text #’+ means in Lisp the functional object associated to the 
standard addition operator ' + ’. Test: 
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> (funcall #’+ 4 5) >J< 
9 


The value of the expression #’ + is #<Function +>, an external simple represen¬ 
tation of the functional object, too complicated to be exactly displayed, it is some 
machine code, readable only by experts. 

Our programmer uses also the multiplicative monoid of the integers. 


> (setq N* (list 1 #’*)) ^ 
(1 #<Function *>) 

> (funcall #’* 4 5) ►£< 

20 


An identity function is defined to legibly extract the identity of a monoid. 


> (setq identity 

(lambda (monoid) 

(first monoid))) 

#<Interpreted Function (unnamed) @ #x20eafbl2> 

> (funcall identity N+) 

0 


And an operation function is also defined to conveniently compute inside some 
monoid; the second statement below constructs a list made of the respective “prod¬ 
ucts” of 4 and 5 in the monoids N+ and N*. 


> (setq operation 

(lambda (monoid iteml item2) 

(funcall (second monoid) iteml item2))) 
#<Interpreted Function (unnamed) @ #x20eb9cca> 

> (list (funcall operation N+ 4 5) 

(funcall operation N* 4 5)) 

(9 20) 


Now we implement the product bifunctor. If Mi and M 2 are two monoids, an 
element of Mi x M 2 is represented as a pair. So that the identity of Mi x M 2 is 
the pair of the respective identities. The function which, given the monoids Mi 
and M 2 , constructs the identity of M\ x M 2 therefore is: 


> (setq monoid-product-identity 
(lambda (monoidl monoid2) 

(list (funcall identity monoidl) (funcall identity monoid2)))) ^ 
#<Interpreted Function (unnamed) @ #x20ec729a> 

CL-USER(120): (funcall monoid-product-identity N+ N*) 

(0 1 ) 


We did not yet have seen any closure. In the same way, we must be able to 
construct, given two arbitrary monoids Mi and M 2 , the operation of the product 
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monoid Mi x M 2 . 


> (setq monoid-product-operation 

(lambda (monoidl monoid2) 

(lambda (iteml item2) 

(list (funcall operation monoidl 

(first iteml) (first item2)) 
(funcall operation monoid2 

(second iteml) (second item2)))))) 
#<Interpreted Function (unnamed) @ #x20ef3f92> 

> (funcall monoid-product-operation N+ N*) 

#<Interpreted Closure (unnamed) 0 #x20ef9102> 


The operation to be constructed uses the operation of the first monoid and 
makes it work on the first components of the “items”, the same for the second 
components with respect to the second monoid, and finally makes a pair, a list, 
with both results. 

Using this constructor with respect to our monoids N+ and N* this time produces 
a closure. The point is that the internal (lambda (iteml . . .) . . .) uses monoidl 

and monoid2 constituting the local environment where the functional object is 
generated, so that this environment must be saved , it is the role of the closure 
technology. 

We have now in our toolbox the necessary ingredients allowing us to implement 
the product bifunctor. 


> (setq monoid-product 

(lambda (monoidl monoid2) 

(list (funcall monoid-product-identity monoidl monoid2) 

(funcall monoid-product-operation monoidl monoid2)))) ^ 
#<Interpreted Function (unnamed) @ #x20f00c52> 

> (setq N+_x_N* (funcall monoid-product N+ N*)) ^ 

((0 1) #<Interpreted Closure (unnamed) @ #x20f06ae2>) 

> (funcall operation N+_x_N* 

(list 4 4) (list 55)) 

(9 20) 


In other words, in the monoid N+xN*, the product of (4,4) and (5,5) is (9, 20). Now 
these constructors can be used for arbitrary monoids. For example the monoid CS 
of the character strings and their concatenation is constructed in Lisp as follows. 
Using the generic function concatenate of Lisp, a specific function string-conc is 
constructed, giving the second component of our monoid; the identity is the empty 
string. 


> (setq string-conc 
(lambda (stringl string2) 

(concatenate ’string stringl string2))) ^ 
#<Interpreted Function (unnamed) 0 #x20ded9a2> 

> (funcall string-conc "qwert" "yuiop") ^ 
"qwertyuiop" 
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> (setq CS (list "" string-conc)) 

("" #<Interpreted Function (unnamed) 0 #x20ded9a2>) 

> (funcall operation CS "qwert" "yuiop") 
"qwertyuiop" 


The product CS x N+ is then constructed and tested: 


> (setq CS_x_N+ (funcall monoid-product CS N+)) 

(("" 0) #<Interpreted Closure (unnamed) @ #x20e8ea6a>) 

> (funcall operation CS_x_N+ 

(list "qwert" 4) (list "yuiop" 5)) ^ 
("qwertyuiop" 9) 


The product CS x (N+ x N*) is constructed in the same way. 


> (setq CS_x_[N+_x_N*] 

(funcall monoid-product CS N+_x_N*)) ^ 

(("" (0 1)) #<Interpreted Closure (unnamed) 0 #x20eb02b2>) 

> (funcall operation CS_x_[N+_x_N*] 

(list "qwert" (list 45)) 

(list "yuiop" (list 4 5))) 

("qwertyuiop" (8 25)) 


The product bifunctor is present in our environment and can be used as in 
category theory. Its main component is a functional object constructing a new 
functional object from two other functional objects, the closure notion allowing 
the user to naturally construct this higher functional object, for the constructed 
closure “keeps” the environment where it has been generated. In this way, arbi¬ 
trary complex uses of the product bifunctor can be done whithout any confusion: 
every closure will see the right references. And the complexity cost in this case 
is constant, only the addresses of monoidl and monoid2 are used; the code con¬ 
stituting the heart of the function monoid-product-operation being once for all 
installed in the environment, which code can be used by any product of monoids, 
thanks to the indirect addressing mechanism. 


13 When computing homotopy groups. 

Computing the homotopy groups of a finite simply connected simplicial set, or 
more generally a simply connected simplicial set with effective homology , using 
its Whitehead or Postnikov tower, is just the application of a long sequence of 
applications of functors similar to the one used as example in the previous section. 
For example the construction of dx, from W-i discussed in Section [4] is obtained 
by such a long process, and the same for the other components of Xf 

When the functional components of the initial objects are polynomial, all the 
used functors are so simple that of course the resulting objects obviously again 
have polynomial functional components. 
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But this is not enough: the “measure of polynomiality” of the output functional 
objects must in turn polynomially depend on the measure of polynomiality of the 
inputs. 

The final scaffolding of functors is certainly a little impressive, but once you 
master the notion of closure, the proof of polynomiality is a simple recursive pro¬ 
cess. 

We just give here a minimal significant example of the method to be applied. 
Let A, B , C, D be four “ordinary” types of objects for which a size is defined, such 
as integers, lists of such objects, matrices of such objects, etc. Let [A B] (resp. 
[C —> D]) be the functional types of the functional objects which, when an input 
is an clement of A (resp. C), return an element of B (resp. D). Let finally 
a G [[A —> B] —> [C —* D]\ be a sort of “functor” between these functional types. 
Question, how to define the polynomiality of a? 

We would like to express that any polynomiality of / : A — > B implies some 
polynomiality of a(f ) : C —>■ D, but in a “polynomial” way. After a little work, 
you quickly find the appropriate definitions are the following ones. 

Definition 1 — A functional object f : A — »• B is an element of Pf (A, B ) if for 
any element a G A, the estimate r(f,a) < c( 1 + cr(a)) d holds, where a (a) is the 
size of the input a and r(/, a) is the computing time of the output f(a). 

Definition 2 — The functional object a : [A — * B] — » [C —» D\ is polynomial if 
for every degree d G N, there exists a degree d' E N and a polynomial Xd G N[c] 
satisfying the following requirement: if f G P d (A, B), then «(/) G . 

In particular, no type of relation between d! and d is required, but a unique d! 
must be associated to a fixed d\ on the contrary the “measure of d'-polynomiality” 
of oi(f) must polynomially depend on the “measure of d- polynomiality” of /. 

It is then obvious the composition of polynomial maps /* : [Aj_i —» —> 

[Ai Bf\ is again polynomial. 

The reader must be lucid: the definitions above concern the relations between 
the respective complexities of a : A —» B and /(a) : C —> D, and not the com¬ 
plexity of / itself. In the case of the Kenzo program, this complexity is uniformly 
bounded by a constant and can finally be omitted. This is the point never studied 
in [5|. In more complex situations, the complexity of / could have a non-negligible 
role. 

Also, you must handle more complicated cases where inputs and outputs are 
mixtures of “ordinary” objects with an “ordinary” size and functional objects 
of arbitrary level. There is an essentially unique way to extend the simple case 
explained above to the general situation; it is not useful to detail this point here. 

In this way, the Kenzo algorithm can be mathematically described exactly as 
it was programmed many years ago, directly following Postnikov; and the desired 
polynomiality proof is then quite simple; and correct. 
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14 Functional vs Ordinary programming. 


To be complete, it is probably useful to detail the exact status of functional pro¬ 
gramming with respect to “ordinary” programming. 

The standard definitions of theoretical programming carefully distinguish the 
primitive recursive programs from the general recursive programs; necessarily il¬ 
lustrated by the example of the Ackermann function, which can be programmed 
as a general recursive program, not as a primitive recursive program. A reader of 
this text could wonder whether there exists such a theoretical difference between 
functional programming and ordinary programming. 

In a sense, this text proves there is no difference. The closure technology is 
nothing but a process translating a functional program into an ordinary program, 
so that you cannot program more algorithms with functional programming. But 
if you do not want to use functional programming, you will have to manage by 
yourself the serious related problem of identifier scope. The closure technology has 
precisely been invented to free the user of these low level programming problems, 
without any cost in complexity, thanks to a skilful use of indirect addressing. 

The reader could usefully consult again the Wikipedia page “Closure (computer 
programming)”; it is there explained the so-called functional languages all have 
integrated the notion of closure, in a so essential way that the keyword closure 
is even not present in these languages: their users employ closures as Monsieur 
Jourdain wrote in prose. 

In the same Wikipedia page, it is explained how in the other languages it is 
possible to explicitly implement closures if necessary; the object oriented program¬ 
ming tool is then often used to solve the problem of identifier scope, while in fact 
this tool is not at all devoted to this matter. Once these techniques are under¬ 
stood, you should be able to translate the Lisp Kenzo program into any other 
language, with a source code, for the non-functional languages, certainly much 
less convenient; ask for example Google(composel c++) to see the problems met 
by the C++-writers of the toy example of Section [5] and imagine them translating 
the 16000 lines of Kenzo in C++. 

But using these (pseudo-)alternatives does not change anything to the problem: 
anyway, functional objects have to be dynamically generated during the execution 
of the program and you must control the cost of these generations. If you can 
prove the cost of the generation of one functional object is uniformly bounded 
- be careful: independently of the size of the initial object — you have finished. 
Otherwise, you have to study this dependency, good luck! You understand now 
how the closure technology is powerful: in the case of the Kenzo program, it is easy 
to prove the cost of the generation of a closure is uniformly bounded, independently 
of the initial object. 

Other techniques can be used. For example it can be proved the functional 

4 An amusing illustration of which happens without closures is the funny “solution” used by 
Bourbaki !5] to solve this problem by the graphic connections between Hilbert’s t’s and the white 
boxes □. 
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style used in Kenzo can be replaced by a strong recursive style; in fact closer (!) to 
the strict theoretical functional style. More precisely, the bottom-up programming 
style of Kenzo may be replaced by a top-down programming style, producing a 
program where it seems no functional object is dynamically constructed. It is not 
at all convenient, would you like to start the building of a house by the roof and 
finish by the foundations? And this would not change anything in the problem: 
this time you have to study the cost of the handling of the recursiveness, not easy 
in this situation with a terrible graph of crossed multi-recursiveness. And the 
“upside-down” understanding of the algorithm probably makes the complexity 
study rather painful. Anyway it would be a different algorithm. 

In fact, the paper [5] does not give the smallest indication about the solution of 
the authors for this problem. Following the Kenzo program, the authors vaguely 
explain that for any simplicial set with effective homology X, an algorithm rf can 
be written down computing 7T n {X ) which is claimed uniformly polynomial with 
respect to X, but the study of the algorithm X i —> irf is missing. No indication at 
all about which is written before and after (!) launching the execution, for example 
about the Eilenberg-MacLane spaces to be generated , with all their functional 
components, during the execution of wy, see Section [IJ 

Also, trivially using functional programming, the Kenzo program is indepen¬ 
dent of the n of 7r n (X); nothing is said about this point in [5]. It would be funny, 
for a process so simply iterative, to see a program depending on the number of 
steps. 

In summary, the cost of the generation of the countless functional objects is not 
considered in the paper, while it is the heart of the program. Nothing is explained 
either about a possible method to avoid functional programming. Observe in par¬ 
ticular the footnote 11 of [5], which explains “functional programming” could be 
an “alternative” framework to process our complexity problem ; the confusion is 
total: the program as it is described in [5] must inevitably use functional program¬ 
ming; and “functional programming” cannot be a tool to study the complexity of 
an algorithm. 

The article [5] reasonably updated could be a useful introduction to the sub¬ 
ject, but the claimed proof of polynomiality is incomplete. It is true it is difficult 
to master this subject if you do not have any serious concrete experience of pro¬ 
gramming. The same authors, along the same lines, have proved an impressive 
collection of computability and undecidability results, results which, as far as I 
know, are correct; opening, in the positive case, a wonderful field for concrete pro¬ 
gramming. It is a pity to spoil the excellent appreciation due to all these results 
by the paper [5], 
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